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BOOTSTRAP PROTOCOL (BOOTP) 



1 . Status of this Memo 

This RFC suggests a proposed protocol for the ARPA- Internet 
community, and requests discussion and suggestions for improvements. 
Distribution of this memo is unlimited. 

2 . Overview 

This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allbws 
a di skle s s c 1 ient-machine~to-dis cove ri its "Own~I P ~addr e s s , the addr e s s 
of "a server" host , airdnthe~hame~of ' affile to be loaded into memory and 
executed. The bootstrap operation can be thought of as consisting of 
TWO PHASES. This RFC describes the firs^IpKase, which could be 
labeled ' address-deterTninatl'onrandrb^^^^ . After this 

address and filename information is obtained, control passes to the 
seco nd~ phase of the bjootstrap where a file transfer occurs. The file 
transfer will typically use the TFTP protocol [9], since it is 
intended that both phases reside in PROM on the client. However 
BOOTP could also work with other protocols such as SFTP [3] or 
FTP [6] . 

We suggest that the client's PROM software provide a way to do a 
complete bootstrap wit^u^'uTser'" interact^n. This is the type of 
boot that would occur during^n~unat tended power-up. A mechanism 
should be provided for the user to manually supply the necessary 
address and filename information to bypass the BOOTP protocol and 
enter the file transfer phase directly. If non-volatile storage is 
available, we suggest keeping default settings there and bypassing 
the BOOTP protocol unless these settings cause the file transfer 
phase to fail. If the cached information fails, the bootstrap should 
fall back to phase 1 and use BOOTP. 

Here is a brief outline of the protocol; 

1. A single packet exchange is performed. Timeouts are used to 
retransmit until a reply is received. The same packet field 
layout is used in both directions. Fixed length fields of maximum 
reasonable length are used to simplify structure definition and 
parsing. 

2. 'opcode' field exists with two values. The client 
broadcasts a ' bootxeques packet. The server then answers with a 
' bogtxeply-^packet . The bootrequest contains the client's 
hardware address and its IP address, if known. 
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3. The request can optionally contain the name of the server the 
client wishes to r:e:sp:ond. This is so the client can force the 
boot to occur from a specific host (e.g. if multiple versions of 
the same boot:f:i~J:e exist or if the server is in a far distant 
net/domain) . The client does not have to deal with name / domain 
services; instead this function is pushed off to the BOOTP server 

4. The request can optionally contain the 'generic' filename to b 
booted. For example 'unix' or 'ethertip'. When the server sends 
the bootreply, it replaces this field with the fully qualified 
path name of the appropriate boot file. In determining this name 
the server may consult his own database correlating the client's 
address and filename request, with a particular boot file 
customized for that client. If the bootrequest filename is a nul 
string, then the server returns a filename field indicating the 
'default' file to be loaded for that client. 

5. In the case of clients who do not know their IP addresses, the 
server must also have a database relating hardware address to IP 
address. This cl-i'en^1F=I-P"adcires's is tehen^==pl^el!i"i-n%o~a— 
the=:bootr-eply . 

6. Certain network topologies (such as Stanford's) may be such 
that a given physical cable does not have a TFTP server directly 
attached to it (e.g. all the gateways and hosts on a certain cabl 
may be diskless) . With the cooperation of neighboring gateways, 
BOOTP can allow clients to boot off of servers several hops away, 
through these gateways. See the section 'Booting Through 
Gateways' below. This part of the protocol requires no special 
action on the part of the client. Implementation is optional and 
requires a small amount of additional code in gateways and 
servers . 

3 . Packet Format 

All numbers shown are decimal, unless indicated otherwise. The BOOT 
packet is enclosed in a standard IP [8] UDP [7] datagram. For 
simplicity it is assumed that the BOOTP packet is never fragmented. 
Any numeric fields shown are packed in 'standard network byte order' 
i.e. high order bits are sent first. 

In the IP header of a bootrequest, the client fills in its own IP 
source address if known, otherwise zero. When the. server address is 
unknown, the IP destination address will be the 'broadcast address' 
255.255.255.255. This address means 'broadcast on the local cable. 
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(I don't know my net nximber) ' [4]. 
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The UDP header contains source and destination port numbers. The 
BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68) 
and 'BOOTP server' (67) . The client sends requests using 'BOOTP 
server' as the destination port; this is usually a broadcast. The 
server sends replies using 'BOOTP client' as the destination port; 
depending on the kernel or driver facilities in the server, this may 
or may not be a broadcast (this is explained further in the section 
titled 'Chicken/Egg issues' below). The reason TWO reserved ports 
are used, is to avoid 'waking up' and scheduling the BOOTP server 
daemons, when a bootreply must be broadcast to a client. Since the 
server and other hosts won't be listening on the 'BOOTP client' port 
any such incoming broadcasts will be filtered out at the kernel 
level. We could not simply allow the client to pick a 'random' port 
number for the UDP source port field; since the server reply may be 
broadcast, a randomly chosen port number could confuse other hosts 
that happened to be listening on that port. 

The UDP length field is set to the length of the UDP plus BOOTP 
portions of the packet. The UDP checksiim field can be set to zero b 
the client (or server) if desired, to avoid this extra overhead in a 
PROM implementation. In the 'Packet Processing' section below the 
phrase ' [UDP checksum.] ' is used whenever the checksum might be 
verified/computed. 

FIELD BYTES DESCRIPTION 



op 



packet op code / message type. 
1 = BOOTREQUEST, 2 = BOOTREPLY 



htype 



hardware address type, 

see ARP section in "Assigned Numbers" RFC. 
'1' = lOmb ethernet 



hlen 



hardware address length 
(eg '5' for lOmb ethernet). 



hops 



client sets to zero, 
optionally used by gateways 
in cross-gateway booting. 



xid 



transaction ID, a random number. 
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used to match this boot request with the 
responses it generates. 



sees 



filled in by client, seconds elapsed since 
client started trying to boot. 
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ciaddr 4 

yiaddr 4 

siaddr 4 

giaddr 4 

chaddr 16 

sname 64 

file 128 



vend 64 



4. Chicken / Egg Issues 



unused 

client IP address; 

filled in by client in bootrequest if known. 

'your' (client) IP address; 
filled by server if client doesn't 
know its own address (ciaddr was 0) . 

server IP address; 

returned in bootreply by server. 

gateway IP address, 

used in optional cross-gateway booting. 

client hardware address, 
filled in by client. 

optional server host name, 
null terminated string. 

boot file name, null terminated string; 
'generic' name or null in bootrequest, 
fully qualified directory-path 
name in bootreply. 

optional vendor-specific area, 
e.g. could be hardware type/serial on request, 
or 'capability' / remote file system handle 
on reply. This info may be set aside for use 
by a third phase bootstrap or kernel. 



Hp>?^Gan^tiie^='s^-vea^se^^^ i ent 

doe^nt=^lmovr=rf^^ Whenever a bootreply is being 

sent, the transmitting machine performs the following operations: 

1. If the client knows its own IP address ('ciaddr' field is 
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nonzero)/ then the IP can be sent 'as normal', since the client 
will respond to ARPs [5] . 



2 . I f the^H^W^o ) / 

then-the-^cTi^se^^eanii^^^^ of 
the-bootrepiy. There are two options: 

a. If the transmitter has the necessary kernel or driver hooks 



to 'manually' conS:t'ruct::::an-:ARP^dd^e¥s=^^ then it ca 

f idi:iiini:an7:entr_yrir^^^ • Of 

course, this entry should have a timeout on it, just like any 

other entry made by the normal ARP code itself._The ^ 

transmitter of the b ootre ply can then simp¥y=&end--f he-boot repl 
to~the~ci:rertt^?=s=^-P^^ UNIX (4.2 BSD) has this 

capability. 

b. If the transmitter lacks these^ kernel^ hooks, it can simply 
send— the-boot:r]epT>y to the I;Pi:broadcas£radclxig5S on the 
appropriate^ interface. This is only one additional broadcast 
over the previous case. 



5. Client Use of ARP 

The cl'ren't'~PR0M-7must contain a simple implementation of ,^lRP, e.g. th 
address^cache^ould be just one entry in size. This will allow a 
se:cOTT<tepha's;e^on±y^ (TFTP) to be performed when the c Id ent; ? knows 

the'^^^^^^^^^^aSdresses and bootfile name. 

Any time the client is expecting to receive a TFTP or BOOTP reply, i 
should be prepared to an'swe^aS^^^ARPlIrequest for r- ij:s"Own"T P^ to 
ha^dwaS^^^^dfess^ . 

Since the bootreply will contain (in the hardware encapsulation) the 
hardware source address of the server/gateway, the client MAY be abl 
to avoid sending an ARP request for the server/gateway IP address to 
be used in the following TFTP phase. However this should be treated 
only as a special case, since it is desirable to still allow a 
second-phase-only boot as described above. 

6. Comparison to RARP 

An earlier protocol. Reverse Address Resolution Protocol . CRARP) [1] 
was:^proposed==fo^l=lW^=a^ s , given 

that-i~t:=kn^vFa^t^h^ However RARP had the disadvantag 
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that it cwas==^a=hardware^ti'^^ . This 

means that RARP couid" on±y:^be~ impieme^n^^^ specia 

ke r nefcor-drtve i;^modi=f^^^^ to ^aee^es^t^hes^^^'=r£^^ t s . Since 

there are many network kernels existent now, with each source 

maintained by different organizations, a boot protocol that does not 
require kernel modifications is a decided advantage. 

B00T-P provides this hardware-tor=lTP-address-rd'OG^^^ in 
addition to the other useful features described in the sections 
above . 
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7. Packet Processing 

7.1. Client Transmission 

Before setting up the packet for the first time, it is a good ide 
to clear the entire packet buffer to all zeros; this will place 
all fields in their default state. The cltent=^1^Ken=^ca?ea^tes a 
p a eke tr-.w±t h3:t his^f ~G~13.^^ elds. 

The IP de:s-t±nat±on-addre^ss is set to 255.255.255.255. (the 
broadcast address) or to the server's IP address (if known). The 
IP source address and 'ciaddr' are set to the client's IP address 
if known, else 0. The UDP header is set with the proper length; 
source port = 'BOOTP client' port destination port = 'BOOTP 
server ' port . 

'op' is set to '1', BOOTREQUEST. 'htype' is set to the hardware 
address type as assigned in the ARP section of the "Assigned 
Numbers" RFC. 'hlen' is set to the length of the hardware address 
e.g. '6' for lOmb ethernet. 

'xid' is set to a 'random' transaction id. 'sees' is set to the 
number of seconds that have elapsed since the client has started 
booting. This will let the servers know how long a client has 
been trying. As the number gets larger, certain servers may feel 
more 'sympathetic' towards a client they don't normally service. 
If a client lacks a suitable clock, it could construct a rough 
estimate using a loop timer. Or it could choose to simply send 
this field as always a fixed value, say 100 seconds. 

If the client knows its IP address, 'ciaddr' (and the IP source 
address) are set to this value. 'chaddr' is filled in with the 
client's hardware address. 
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If the client wishes to restrict booting to a particular server 
name, it may place a null-terminated string in 'sname'. The name 
used should be any of the allowable names or nicknames of the 
desired host. 

The client has several options for filling the 'file' name field. 
If left null, the meaning is 'I want to boot the default file for 
my machine'. A null file name can also mean 'I am only intereste 
in finding out client/server/gateway IP addresses, I dont care 
about file names'. 

The field can also be a 'generic' name such as 'unix' or 
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'gateway'; this means 'boot the named program configured for my 
machine'. Finally the field can be a fully directory qualified 
path name. 

The 'vend' field can be filled in by the client with 
vendor-specific strings or structures. For example the machine 
hardware type or serial number may be placed here. However the 
operation of the BOOTP server should not DEPEND on this 
information existing . 

If the 'vend' field is used, it is recommended that a 4 byte 
'magic number' be the first item within 'vend' . This lets a 
server determine what kind of information it is seeing in this 
field. Numbers can be assigned by the usual 'magic number' 
process — you pick one and it's magic. A different magic number 
could be used for bootreply's than bootrequest ' s to allow the 
client to take special action with the reply information. 

[UDP checksum. ] 

7.2. Client Retransmission Strategy 

I f cno^^r^gryTiXTrea^ 

shgu±d~reti^^ The time interval must be chosen 

carefully so as not to flood the network. Consider the case of a 
cable containing 100 machines that are just coming up after a 
power failure. Simply retransmitting the request every four 
seconds will inundate the net. 

As a possible strategy, you might consider backing off 
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exponentially/ similar to the way ethernet backs off on a 
collision. So for example if the first packet is at time 0:00, 
the second would be at :04, then :08, then :16, then :32, then 
: 64 . You should also randomize each time; this would be done 
similar to the ethernet specification by starting with a mask and 
'and'ing that with with a random number to get the first backoff. 
On each succeeding backoff, the mask is increased in length by on 
bit. This doubles the average delay on each backoff. 

After the 'average' backoff reaches about 60 seconds, it should b 
increased no further, but still randomized. 

Before each retransmission, the client should update the 
field. [UDP checksum.] 
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7.3. Server Receives BOOTREQUEST 

[UDP checksum.] If the UDP destination port does not match the 
'BOOTP server' port, discard the packet. 

If the server name field (sname) is null (no particular server 
specified) , or sname is specified and matches our name or 
nickname, then continue with packet processing. 

If the sname field is specified, but does not match 'us', then 
there are several options: 

1. You may choose to simply discard this packet. 

2. If a name lookup on sname shows it to be on this same cable 
discard the packet. 

3. If sname is on a different net, you may choose to forward 
the packet to that address. If so, check the 'giaddr' (gatewa 
address) field. If 'giaddr' is zero, fill it in with my 
address or the address of a gateway that can be used to get to 
that net. Then forward the packet. 

If the client IP address (ciaddr) is zero, then the client does 
not know its own IP address. Attempt to lookup the client 
hardware address (chaddr, hlen, htype) in our database. If no 
match is found, discard the packet. Otherwise we now have an IP 
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address for this client; fill it into the 'yiaddr' (your IP 
address) field. 



We now check the boot file name field (file) . The field will be 
null if the client is not interested in filenames, or wants the 
default bootfile. If the field is non-null, it is used as a 
lookup key in a database, along with the client's IP address. If 
there is a default file or generic file (possibly indexed by the 
client address) or a fully-specified path name that matches, then 
replace the 'file' field with the fully-specified path name of th 
selected boot file. If the field is non-null and no match was 
found, then the client is asking for a file we dont have; discard 
the packet, perhaps some other BOOTP server will have it. 

The 'vend' vendor-specific data field should now be checked and i 
a recognized type of data is provided, client-specific actions 
should be taken, and a response placed in the 'vend' data field o 
the reply packet. For example, a workstation client could provid 
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an authentication key and receive from the server a capability fo 
remote file access, or a set of configuration options, which can 
be passed to the operating system that will shortly be booted in. 

Place my (server) IP address in the 'siaddr' field. Set the 'op' 
field to BOOTREPLY. The UDP destination port is set to 'BOOTP 
client'. If the client address 'ciaddr' is nonzero, send the 
packet there; else if the gateway address 'giaddr' is nonzero, se 
the UDP destination port to 'BOOTP server' and send the packet to 
'giaddr'; else the client is on one of our cables but it doesnt 
know its own IP address yet — use a method described in the 'Egg' 
section above to send it to the client. If 'Egg' is used and we 
have multiple interfaces on this host, use the 'yiaddr' (your IP 
address) field to figure out which net (cable/interface) to send 
the packet to. [UDP checksum.] 

7.4. Server/Gateway Receives BOOTREPLY 

[UDP checksiom.] If 'yiaddr' (your [the client's] IP address) 
refers to one of our cables, use one of the 'Egg' methods above t 
forward it to the client. Be sure to send it to the 'BOOTP 
client' UDP destination port. 

7.5. Client Reception 
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Don't forget to process ARP requests for my own IP address (if I 
know it). [UDP checksum,] The client should discard incoming 
packets that: are not IP/UDPs addressed to the boot port; are not 
BOOTREPLYs; do not match my IP address (if I know it) or my 
hardware address; do not match my transaction id. Otherwise we 
have received a successful reply, 'yiaddr' will contain my IP 
address, if I didnt know it before. 'file' is the name of the 
file name to TFTP 'read request'. The server address is in 
'siaddr'. If 'giaddr' (gateway address) is nonzero, then the 
packets should be forwarded there first, in order to get to the 
server. 

8. Booting Through Gateways 

This part of the protocol is optional and requires some additional 
code in cooperating gateways and servers, but it allows cross-gatewa 
booting. This is mainly useful when gateways are diskless machines. 
Gateways containing disks (e.g. a UNIX machine acting as a gateway), 
might as well run their own BOOTP/TFTP servers. 

Gateways listening to broadcast BOOTREQUESTs may decide to forward o 
rebroadcast these requests 'when appropriate' . For example, the 
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gateway could have, as part of his configuration tables, a list of 
other networks or hosts to receive a copy of any broadcast 
BOOTREQUESTs. Even though a 'hops' field exists, it is a poor idea 
to simply globally rebroadcast the requests, since broadcast loops 
will almost certainly occur. 

The forwarding could begin immediately, or wait until the 'sees' 
(seconds client has been trying) field passes a certain threshold. 

If a gateway does decide to forward the request, it should look at 
the 'giaddr' (gateway IP address) field. If zero, it should plug it 
own IP address (on the receiving cable) into this field. It may als 
use the 'hops' field to optionally control how far the packet is 
reforwarded. Hops should be incremented on each forwarding. For 
example, if hops passes '3', the packet should probably be discarded 
[UDP checksum.] 

Here we have recommended placing this special forwarding function in 
the gateways. But that does not have to be the case. As long as 
some 'BOOTP forwarding agent' exists on the net with the booting 
client, the agent can do the forwarding when appropriate. Thus this 
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service may or may not be co-located with the gateway. 



In the case of a forwarding agent not located in the gateway, the 
agent could save himself some work by plugging the broadcast address 
of the interface receiving the bootrequest into the 'giaddr' field. 
Thus the reply would get forwarded using normal gateways, not 
involving the forwarding agent. Of course the disadvantage here is 
that you lose the ability to use the 'Egg' non-broadcast method of 
sending the reply, causing extra overhead for every host on the 
client cable. 

9. Sample BOOTP Server Database 

As a suggestion, we show a sample text file database that the BOOTP 
server program might use. The database has two sections, delimited 
by a line containing an percent in column 1. The first section 
contains a 'default directory' and mappings from generic names to 
directory/pathnames. The first generic name in this section is the 
'default file' you get when the bootrequest contains a null 'file' 
string. 

The second section maps hardware addresstype/address into an 
ipaddress. Optionally you can also overide the default generic name 
by supplying a ipaddress specific genericname. A 'suffix' item is 
also an option; if supplied, any generic names specified by the 
client will be accessed by first appending 'suffix' to the 'pathname 
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appropriate to that generic name. If that file is not found, then 
the plain 'pathname' will be tried. This 'suffix' option allows a 
whole set of custom generics to be setup without a lot of effort. 
Below is shown the general format; fields are delimited by one or 
more spaces or tabs; trailing empty fields may be omitted; blank 
lines and lines beginning with '#' are ignored. 

# comment line 

homedirectory 
genericname 1 pathnamel 
genericname2 pathname2 

% end of generic names, start of address mappings 

hostnamel hardwaretype hardwareaddrl ipaddrl genericname suffix 
hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix 
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Here is a specific example. Note the 'hardwaretype' number is the 
same as that shown in the ARP section of the 'Assigned Numbers' RFC, 
The 'hardwaretype' and 'ipaddr' numbers are in decimal; 
' hardwareaddr ' is in hex. 

# last updated by smith 



/usr/boot 
vmunix 

tip 

watch 

gate 



vmunix 
ethertip 

/usr/diag/etherwatch 
gate . 



% end of generic names, start of address mappings 



hamilton 1 

burr 1 

101-gateway 1 

mjh-gateway 1 

welch-tipa 1 

welch-tipb 1 



02. 60. 8c. 06. 34. 98 
02. 60. 8c. 34. 11. 78 
02. 60. 8c. 23. ab. 35 
02. 60. 8c. 12. 32. be 
02. 60. Sc. 22. 65.32 
02. 60. 8c. 12. 15. c8 



36,19.0.5 

36.44.0.12 

36.44.0.32 

36.42.0.64 

36.47.0.14 

36.46.0.12 



gate 101 
gate mjh 
tip 
tip 



In the example above, if 'mjh-gateway' does a default boot, it will 
get the file ' /usr/boot/gate .mjh' . 
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